Name-address management generally includes issues such as name-to-address resolution and name-address registration. Name-to-address resolution is a procedure by which a “name” of a network resource, e.g., a network node, is resolved or translated into a routable network address, i.e., a location in the network topology. Name-address registration is the corresponding registration procedure by which the name and the assigned network address of the resource are registered in the network. The name of the resource is normally known to users and typically also stays the same over relatively long periods of time.
Traditional networking architectures for the Public Switched Telephone Network (PSTN) or Internet solve the problem of connecting terminals or hosts (which can be considered as “boxes”) in order to support a specific application such as telephony or WWW. To this end, traditional naming and addressing schemes employ host or network centric identities such as E.164 numbers for telephony, or Internet Protocol (IP) addresses and Uniform Resource Locators (URLs) for the Internet. However, the end user is typically interested in reaching a destination object that sits behind or within the box, such as a human being or a file, rather than communicating with the box itself. As the destination objects move to new boxes, box or network dependent identities of these objects must be updated. For example, it is an everyday experience that a person cannot be reached at the phone number registered in some semi-static directory because that directory does not track the phone that she is momentarily close to. Or a web link is broken because the target data object has been moved to another location. To address this class of problems, box-independent addressing schemes such as Telephone Number Mapping (ENUM), Session Initiation Protocol (SIP) names, and Uniform Resource Identifiers (URIs) have been developed. Using a presence or mobility mechanism, box-independent names of a destination object can then be mapped to the address of the box where the destination object is currently located. Likewise, inventory systems are used to track specific objects to a specific location.
The Domain Name System (DNS) stores and provides information associated with domain names in a distributed database in networks such as the Internet. The DNS associates domain names with many types of information, but most importantly it provides the IP address for a given domain name. DNS makes it possible to associate easy-to-remember domain names (such as ericsson.com) with hard-to-remember IP addresses. DNS is suitable for resources that rarely change their location, but is not adapted for mobility. RFC 2136 describes “Dynamic Updates in the Domain Name System” in the hope of providing better support for rapid updates of DNS, but it is still far from being suitable for keeping track of roaming resources such as mobile phones and their users.
When routing protocols for the Internet and other fixed networks were initially created, hosts were not expected to move around. Therefore, hosts are usually named by their point of attachment to the network, e.g., IP addresses. Examples of routing protocols that perform routing based on IP addresses include RIP, IS-IS, OSPF, BGP and PNNI. These are all well established technologies but have limited support for mobility and have convergence problems when network topologies change rapidly.
Traditionally, applications use IP-addresses in a way that does not allow them to change during an on-going session. To allow hosts to move without changing their IP-addresses (at least from an application perspective) mobility solutions in IP networks, such as Manet (Mobile ad hoc networks), Network Mobility (NEMO), and Mobile IP have been developed. But these are fairly complex solutions since they adapt a technology intended for fixed networks to new mobility requirements.
The Host Identity Protocol (HIP) (see IETF RFC 4423) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space based on public keys. The public keys are typically self-generated. The HIP separation can be used to provide end-to-end connectivity over different locator domains. Even still, routing protocols under development cater to mobility of individual hosts (nodes) but do not adequately address the problems relating to mobile networks (MNs). A mobile network includes a group of many mobile hosts or other objects that move together as a group. Mobile network examples include networks located in any type of mobile vehicle, e.g., in a train, airplane, bus, ship, subway, etc., but are not limited to vehicles. All that is required is that the group of mobile objects, hosts and routers move substantially together at substantially the same time. Also, a communication satellite carrying a router is another example of a mobile network that dynamically attaches to ground stations, other communication satellites, and hosts or mobile phones. A particular mobility problem associated with mobile networks is a potentially huge number of registration or other location updates that need to be signaled and processed whenever the mobile network changes location. Such a move may cause an “update storm.”
Consider for example a Public Land Mobile Network (PLMN) type of system like GSM and 3G cellular networks. Mobile host name resolution is handled via a Home Location Register (HLR) and the Visited Location Register (VLR). When a mobile host is called, a phone number (MS-ISDN) is resolved via the VLR and HLR into a corresponding E.164 address that allows the call to be routed to the mobile host, if the mobile host with the MS-ISDN has registered its current location area with the VLR. Local mechanisms are used to route the call to the specific cell in the location area in which the mobile host is currently located.
The HLR and VLR have overall good performance and security support regarding name resolution in cellular systems. But they are closely linked to the E.164 address structure and as such do not provide an open architecture for other and/or arbitrary name and address spaces. Moreover, this approach to registering a host with a centralized location register like the HLR/VLR does not function well with mobile networks. The problem is particularly acute when a large mobile network with many subnetworks or hosts roams and requires registration update signaling for every one of its subnetworks and/or hosts—a good example of an “update storm” mentioned above.
In dynamic DNS, when such a mobile network roams, each host in the mobile network must have its DNS record updated. For that situation, mobile IP requires that all home agents having hosts in the mobile network be updated. RFC 3963 describes the IETF Network Mobility (NEMO) basic support protocol that enables mobile networks to attach to different points in the Internet. The protocol is an extension of mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while mobile around. But NEMO's distributed solution suffers from what is called “pinball routing,” where all internetwork traffic must be routed between every mobility agent that has an associated mobile node or network in the path towards the destination host. As a result, tunneling overhead accumulates per radio hop, and there are potential latency problems when several mobility agents are located at different continents.
As illustrated in FIG. 1, it is known to provide a set of attachment registers 14 in a network 12, where the attachment registers perform one or more network functions. A primary function of the attachment registers is to store a locator point of an object reachable from a network. For example, Attachment Register A (ARA) stores a locator point of network A 16. Information is stored in the attachment registers that establishes one or more logical links between attachment registers. In the example shown in FIG. 1, the arrows between the attachment registers 14 indicate that information stored in attachment register ARD links to attachment register ARC. Similarly, information in ARC links to ARB, and information in ARB links to ARA. The information in these attachment registers creates a path to host D, and thus allows easy construction of a global locator to host D. By using attachment registers, a global locator can be constructed to a host attached to a network even where the network or an intermediate network changes location. Only the hosts that have ongoing communication sessions need to update their global locator.
To illustrate how a global locator may be constructed, FIG. 2 illustrates an example of four networks having locally unique interface numbers between each network. A globally unique locator for a host can be constructed by concatenating a sequence of interface numbers with a globally unique locator of an Edge Router (ER). The interface numbers are locally unique for each network. In this example, host H3 201 can be reached from the ER 202 via the symbolic address (r,2,3,2). The “r” in the address is the globally unique locator for the ER 202, and each subsequent number is a Local Interface Number (LIN) of each egress interface (that is, the exit point from one mobile network to another mobile network) that is traversed on a path from the ER 202 to H3 201. The first “2” in the address relates to the interface number from the ER 202 to Mobile Network B (MNB) 203, the subsequent “3” in the address relates to the interface number from MNB 203 to Mobile Network D (MND) 204, and the final “3” relates to the interface number from MND 204 to Host H3 201. In this way, a globally unique locator for any host H can be constructed with the globally unique locator of the ER and concatenating the egress LIN for each network. Note that host H3 201 could also be reached using the symbolic address (r,1,3,2) or even (r,1,2,4,3,2).
The symbolic address for a host can be encoded into a binary string similar to an IP address. For example, the locator r of ER 202 can be mapped to a 48 bit Ipv6 prefix, and each LIN in the symbolic address can be mapped to, for example, an 8-bit number. Using the example symbolic address to H3 of (r,2,3,2), three LINs are required to describe the path from the ER 202 to the host H3 201. The total locator bit length is therefore 48+(3×8)=72 bits. This means that 56 of the 128 bits of an Ipv6 address are not used. In fact, with a prefix length of 48 bits and a LIN size of 8 bits, ten LINs can be concatenated within an Ipv6 address.
Each LIN has the form m/n, where m is a numerical value and n is the number of bits, and each LIN may have a separate value for n. Where a host is addressed with such a binary string, when a network receives a packet with a source or destination global locator, the network must determine which part of the global locator is to be parsed. To indicate this information to the network, a pointer is carried in the packet header and is updated at every hop of the packet along the path. A router determines the next hop by matching LINs with the segment of the global locator that is pointed out by the pointer and by the number of bits n associated with each LIN. The value of n is local to each network, and is therefore known by the local network node that parses the locator. A pointer pointing at bit 49 in an IPv6 address, combined with the information that the LIN consists of 8 bits, results in a bit mask for bits 49-56. After parsing these bits, the pointer is incremented by n bits, (i.e. to 57 in this example) by the local network node before the packet is forwarded to the next network.
It will be seen from FIG. 2 that networks A, B, C and D have identical sets of LINs (at least up to LIN 3). A LIN is therefore only unique in the context of a particular network. A globally unique locator can therefore only be constructed when the LINs are concatenated with globally unique locators for an Edge Router.
The above scheme for constructing a globally unique locator works very well when constructing a global locator that describes a path in the direction to a destination host from an Edge Router. However, the system does not work for constructing a globally unique locator that describes the same path in the direction from the source host to the Edge Router. It will be apparent from FIG. 2 that a path may be constructed from any of hosts H1, H2, H3, H4 to the Edge router using the address (r,1,1,1). This locator is parsed right-to-left when forwarding along a specific path from a source host to the Edge Router. However, since this locator is not globally unique, it cannot be used for forwarding from the Edge Router to a destination host. It is apparent from FIG. 2 that this locator only describes a “bottom-up” path, but does not describe a valid “top-down” path from the Edge Router to a host. Similarly, a locator that describes a “top-down” path cannot be used to describe the same path in the reverse direction. A locator that describes a bottom-up path is therefore not globally unique, and cannot be used for forwarding along the same path in the top-down direction. A source host that sends a packet inserts a bottom-up source locator to describe the path from the host to the edge router. It also inserts a top-down destination locator to describe the path from the edge router to the destination host. The problem is that the destination host that receives a packet with a bottom-up source locator cannot use it to return a packet to the source host for the reasons stated above.